home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Sep 90 / MacApp.Tech$ 9⁄14⁄90 / 1973-Re DoInitUMemory bug-Sep90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  1.6 KB  |  41 lines  |  [TEXT/GEOL]
  1. Item    8727995                         13-Sept-90        00:13PDT
  2.  
  3. From:   MOOF                            Rollin, Keith A
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. Sub:    RE>DoInitUMemory bug with
  8.  
  9. Attn: DacEasy, Wilma Blair,PRT
  10. SentBy: Keith Rollin
  11.         Reply to:   RE>DoInitUMemory bug with 2.0p
  12.  
  13. Les,
  14.  
  15. I wouln't consider this a “DoInitUMemory bug”. I think that what your ISAM
  16. vender is doing is pretty weird. DoInitUMemory is doing the correct thing in
  17. trying to account for that bogus CODE segment; the problem is that the CODE
  18. segment is too high up.
  19.  
  20. Ideally, I think that the ISAM routines you add to your program should simply
  21. be a library you link in along with all of the MacApp and MPW libraries. If,
  22. for some reason, this post patching is necessary, you should assign a name to
  23. that CODE segment, and then have your ISAM loading routine should look for its
  24. extra CODE segment by that name. That way, the ISAM routines are not dependent
  25. on any specific number, and should work with that segment being numbered 82.
  26.  
  27. If you can't get this developer in Podunk, Alaska, to fix his routines, then
  28. by all means, revert to the way DoInitUMemory used to work. Frankly, though,
  29. I'm in a bit of shock. I simply can't believe that there was someone out there
  30. RELYING on this bug...
  31.  
  32. Sigh...I wonder if MacApp should be more defensive about this. It's possible,
  33. for example, to implement an array of two field records - one word to hold a
  34. CODE resource number, and one to hold its size/residency/etc. That way, the
  35. array wouldn't be so sparse and large in odd cases like this.
  36.  
  37. - Keith Rollin
  38. - Apple Developer Technical Support
  39.  
  40.  
  41.